home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1175 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.2 KB

  1. Subject: Re: user-written interrupt handlers
  2. Date: Tue, 8 Mar 94 18:54:42 CET
  3. From: Juergen Lock <nox@jelal.north.de>
  4. In-Reply-To: <9403071106.AA00523@hanauma.jpl.nasa.gov>; from "Howard Chu" at Mar 7, 94 3:06 am
  5. Message-Id: <9403081754.AA00150@jelal.north.de>
  6.  
  7. Howard Chu writes:
  8.  
  9. > >>   Signal handlers aren't good replacements for interrupts; they take too
  10. > >>   much time to be serviced -- maybe a tenth of a second, versus a few
  11. > >>   microseconds for an interrupt handler. It would be unusable, for
  12. > >>   instance, for the serial interrupts, while it would be quite appropriate
  13. > >>   for "Monochrome Detect", say.
  14. > >> 
  15. > >> Well, since my only purpose here was to drive my interrupt-driven sound
  16. > >> routines on the Falcon, that was just fine anyway. (Using the monochrome
  17. > >> detect interrupt, fancy that.)
  18. > >
  19. > > btw what is the difference, isn't monochrome detect level 6 too? :)
  20. > >(not that this should be a problem here...)
  21. > >
  22. > > cheers
  23. > >    Juergen
  24. > Heh. Well, I doubt a monochrome monitor will burn out in a few milliseconds
  25. > of bad video signal, and I know you won't hear a few milliseconds lag in
  26. > swtching the buffer addresses of a DMA-driven sound playback, but you could
  27. > lose several bytes in that amount of time in a serial interrupt handler.
  28.  
  29.  well whether you'll hear it depends on what you play back :) but when a
  30. cat >/dev/audio uses an interrupt handler that takes too long it will
  31. annoy uucico processes running at the same time as well as when its a
  32. serial interrupt handler with this problem...
  33. > It's too bad there weren't a couple more DMA channels in the regular ST;
  34. > like one for the 68901 USART. Running that chip in sync mode would let you
  35. > do some really mean high-speed internetworking...
  36.  
  37.  btw anyone using the TT's SCC DMA yet?  its too bad mega STe don't have it :)
  38. (and have all this SCC problems too.)
  39. > Hm.... Now that I think of it, how could you call post_sig from an rs232
  40. > interrupt handler? You need to get back to receiving the characters of
  41. > the next incoming frame right away, so you need some way of firing off the
  42. > call to post_sig at a lower priority.
  43.  
  44.  hmm.  if there is no one else hooked into the same vector `above' you
  45. you could reset the interrupt level from the stack after flipping the
  46. 68901 in-service bit and then send the signal and rte...  (is post_sig etc
  47. re-entrant(sp?) ?)
  48.  
  49. >  I guess you could set another flag
  50. > to indicate SLIP or PPP end of frame, and have a VBL routine check that...
  51.  
  52.  ...and otherwise (interrupt level on stack was >= 5) do this.
  53. > On a different topic, I've seen my system freeze up completely from time
  54. > to time, only to return to regular operation some indeterminate amount of
  55. > time later. Anyone else seen this? (I'm still talking MultiTOS here.) No
  56. > keypresses or button clicks register, drop-down menus don't drop, etc.,
  57. > only the mouse-cursor tracks. Awfully disconcerting...
  58.  
  59.  maybe the disk driver?  when my quantum disk gets accessed while it
  60. recalibrates i get a few second `sleep' too.  but that has nothing to do
  61. with multitos...
  62.  
  63. >   -- Howard
  64.  cheers
  65.     Juergen
  66. -- 
  67. J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
  68.                                 ...ohne Gewehr
  69. PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA 
  70.